Modeling the Effects of Project Management Strategies on Long-Term Product Knowledge

Abstract in UndeterminedIn a team, people sometimes leave the team and become replaced by new persons with less experience, and sometimes people participate in new activities and thereby obtain new knowledge. Different processes, in terms of different management strategies, can be followed, e.g., to introduce people to new tasks so they get new knowledge. There is a need to investigate the long term effects of different strategies on a team's software product knowledge. This paper presents an initial approach for how this type of knowledge can be modeled as a stochastic process. Metrics representing the long term effects on knowledge are derived, and two different example strategies are investigated numerically. Based on this it is discussed how the model can be further elaborated and evaluated

Introducing empirical software engineering methods in education

Empirical methods are important in software engineering. It is important to be able to evaluate new techniques and methods in a structured way before they are introduced in the software process. This paper presents how empirical methods may be taught by letting students take part in the execution and analysis of empirical investigations in projects. The projects that the students carry out include a role-play where teachers play the roles of managers for the students and responsible for ordering the work of the students. It is found that the project is well received and that it is probable that the students reach the related learning objectives of the cours

Communicating Cybersecurity Vulnerability Information: A Producer-Acquirer Case Study

The increase in both the use of open-source software (OSS) and the number of new vulnerabilities reported in this software constitutes an increased threat to businesses, people, and our society. To mitigate this threat, vulnerability information must be efficiently handled in organizations. In addition, where e.g., IoT devices are integrated into systems, such information must be disseminated from producers, who are implementing patches and new firmware, to acquirers who are responsible for maintaining the systems. We conduct an exploratory case study with one producer of IoT devices and one acquirer of the same devices, where the acquirer integrates the devices into larger systems. Through this two-sided case study, we describe company roles, internal and inter-company communication, and the decisions that need to be made with regard to cybersecurity vulnerabilities. We also identify and discuss both challenges and opportunities for improvements, from the point of view of both the producer and acquirer

How software engineering research aligns with design science: A review

Background: Assessing and communicating software engineering research can be challenging. Design science is recognized as an appropriate research paradigm for applied research but is seldom referred to in software engineering. Applying the design science lens to software engineering research may improve the assessment and communication of research contributions. Aim: The aim of this study is 1) to understand whether the design science lens helps summarize and assess software engineering research contributions, and 2) to characterize different types of design science contributions in the software engineering literature. Method: In previous research, we developed a visual abstract template, summarizing the core constructs of the design science paradigm. In this study, we use this template in a review of a set of 38 top software engineering publications to extract and analyze their design science contributions. Results: We identified five clusters of papers, classifying them according to their alignment with the design science paradigm. Conclusions: The design science lens helps emphasize the theoretical contribution of research output---in terms of technological rules---and reflect on the practical relevance, novelty, and rigor of the rules proposed by the research.Comment: 32 pages, 10 figure

Open Data-driven Usability Improvements of Static Code Analysis and its Challenges

Context: Software development is moving towards a place where data about development is gathered in a systematic fashion in order to improve the practice, for example, in tuning of static code analysis. However, this kind of data gathering has so far primarily happened within organizations, which is unfortunate as it tends to favor larger organizations with more resources for maintenance of developer tools. Objective: Over the years, we have seen a lot of benefits from open source and recently there has been a lot of development in open data. We see this as an opportunity for cross-organisation community building and wonder to what extent the views on using and sharing open source software developer tools carry across to open data-driven tuning of software development tools. Method: An exploratory study with 11 participants divided into 3 focus groups discussing using and sharing of static code analyzers and data about these analyzers. Results: While using and sharing open-source code (analyzers in this case) is perceived in a positive light as part of the practice of modern software development, sharing data is met with skepticism and uncertainty. Developers are concerned about threats to the company brand, exposure of intellectual property, legal liabilities, and to what extent data is context-specific to a certain organisation. Conclusions: Sharing data in software development is different from sharing data about software development. We need to better understand how we can provide solutions for sharing of software development data in a fashion that reduces risk and enables openness

Usage-Based Reading for Inspections of Requirements

Software inspection has proven to be an effective way to increase the quality of software products. A new reading technique suggested for software inspection, usage-based reading (UBR), has been tested in previous studies, where it showed good defect detection efficiency during inspection of design documents. This study addresses the question whether this is true also for inspections of requirements documents. The idea behind UBR is to let prioritized use-cases direct the reviewer’s focus on important parts of the document. Using graduate students as subjects, the UBR approach for inspection of requirement specification was compared with a checklist approach. All defects were classified according to their severity for the function of the final software. The result shows that reviewers using UBR do not find more defects and use more time than those using a checklist. In conclusion, in comparison with a checklist approach, UBR does not make the inspection of requirements specifications more efficient

A Maturity Model for IT Dependability in Emergency Management

In many organisations a gap exists between IT management and emergency managemement. This paper illustrates how process improvement based on a maturity model can be used to help organisations to evaluate and improve the way they include IT dependability information in their emergency management. This paper presents the IDEM3 (IT Dependability in Emergency Management Maturity Model) process improvement framework which focuses especially on the cooperation between IT personnel, emergency managers, and users, to proactively prevent IT dependability problems when the IT systems are most critical in emergency situations. This paper describes the details of the framework, how the framework was developed and its relation to other maturity models in related fields

Different conceptions in software project risk assessment

During software project risk management, a number of decisions are taken based on discussions and subjective opinions about the importance of identified risks. In this paper, different people's opinions about the importance of identified risks are investigated in a controlled experiment through the use of utility functions. Engineering students participated as subjects in the experiment. Differences have been found with respect to the perceived importance, although the experiment could not explain the differences based on undertaken role in a development course

Guidelines for conducting interactive rapid reviews in software engineering -- from a focus on technology transfer to knowledge exchange

Evidence-based software engineering (EBSE) aims to improve research utilization in practice. It relies on systematic methods (like systematic literature reviews, systematic mapping studies, and rapid reviews) to identify, appraise, and synthesize existing research findings to answer questions of interest. However, the lack of practitioners' involvement in the design, execution, and reporting of these methods indicates a lack of appreciation for knowledge exchange between researchers and practitioners. Within EBSE, the main reason for conducting these systematic studies is to answer the practitioner's questions and impact practice. However, in many cases, academics have undertaken these studies without any direct involvement of practitioners.This report focuses on the rapid review guidelines and presents practical advice on conducting these with practitioner involvement to facilitate knowledge co-creation.Based on a literature review of rapid reviews and stakeholders engagement in medicine and our experience of using secondary studies in software engineering, we propose extensions to an existing proposal for rapid reviews in software engineering to increase researchers-practitioners knowledge exchange. We refer to the extended method as an interactive rapid review.An interactive rapid review is a streamlined approach to conduct agile literature reviews in close collaboration between researchers and practitioners in software engineering. This report describes the process and discusses possible usage scenarios and some reflections from the proposal's ongoing evaluation.The proposed guidelines will potentially boost knowledge co-creation through active researcher-practitioner interaction by streamlining practitioners' involvement and recognizing the need for an agile process